EC2をプライベートサブネットに移行した際のアクセス整理（インバウンド・アウトバウンド）
2024.09.20こんにちは！AWS事業本部の吉田です。
最近パブリックサブネットに配置されているEC2をプライベートサブネットに移行することを提案する機会がありました。
EC2をプライベートサブネットに移行した際、EC2周りのアクセスで考えることが思っていたより多いなと感じましたので、記事としてまとめようと思います。
移行前
プライベートサブネット移行前は以下の図の構成と仮定します。
- EC2をパブリックサブネットに配置（EC2にパブリックIPを付与）
- HTTPSアクセスの受け口はALB
- EC2からS3へのアクセスがある
- 作業者からEC2へ直接SSH接続している
- GitHub Actionsを利用して、EC2へデプロイしている
（GitHubホステッドランナーからEC2にSSH接続し、EC2上でgit pullをする）
移行後
プライベートサブネット移行後は、以下の図の構成になります。
以下、それぞれのアクセス方法を説明します。
①ユーザー→EC2
ここは従来通りALB経由でアクセスされます。
EC2をプライベートサブネットに配置することで、直接EC2にアクセスできないようにします。
②EC2→インターネット
NatGatewayを経由してインターネットに出ます。
図では省略しておりますが、厳密にはEC2→NatGateway→InternetGateway→インターネットの順に接続します。
③EC2→AWSリソース(S3など)
EC2→NatGateway→IntenetGateway→AWSリソースという経路でアクセスします。
②の「EC2→インターネット」と似ていますが、この通信はインターネットを経由せずAWSプライベートネットワークに留まります。
Q:2つのインスタンスがパブリックIPアドレスを使用して通信する場合、またはインスタンスがパブリックなAWSのサービスエンドポイントと通信する場合、
トラフィックはインターネットを経由しますか?
A:いいえ。
パブリックIPアドレスを使用する場合、AWSでホストされているインスタンスとサービス間のすべての通信はAWSのプライベートネットワークを使用します。
引用元：https://aws.amazon.com/jp/vpc/faqs/
プライベートサブネットからAWSサービスに接続する方法には、NatGatewayの他にPrivateLink/VPCエンドポイントを利用する方法があります。
どちらの方法が適しているかは、運用の容易性、セキュリティ要件、コストなど、様々な観点から総合的に判断する必要があります。
以下の参考記事を元に判断してください。
AWS PrivateLink・VPCエンドポイントを利用するメリットやユースケースを整理してみた
【AWSコスト最適化】VPC エンドポイントを消すだけでセキュリティそのままにコストが節約できた
EC2のアウトバウンドなどでNatGatewayを利用するかつAWSサービスへの通信量が少ない場合は、
PrivateLink/VPCエンドポイントは無理して使わなくても良いと個人的には思っています。
④作業者→EC2(SSH)
SSM Session Managerというサービスを経由してアクセスします。
このサービスを利用することで、以下のメリットを受けられます。
- キーペアなしで接続可能
- EC2用セキュリティグループにSSHのインバウンドルールが不要
- 踏み台サーバ無しでプライベートサブネットのEC2に接続可能
簡単なイメージ図は以下の通りです。
他にもプライベートサブネットのEC2に対してSSH接続する方法として、EC2 Instance Connect Endpointがあります。
以下の参考記事を参照してください。
EC2 Instance Connect エンドポイント登場！踏み台サーバー不要でパブリックIPのないEC2にSSH・RDPできるようになりました
⑤GitHub→EC2(デプロイ)
CodeDeployというAWSのデプロイサービスを利用します。
詳細な手順は割愛しますが、GitHubとCodeDeployを連携した後、
GitHub ActionsのワークフローでCodeDeployのデプロイを作成するようにすると、
自動的にプライベートサブネットのEC2へ資材をデプロイすることができます。
参考記事：チュートリアル: CodeDeployを使用してGitHubからアプリケーションをデプロイする
さいごに
EC2をプライベートサブネットに移行した際のEC2周りのアクセスを整理してみました。
どなたかのお役に立てれば幸いです。
